fix: create internal application when plugin adds Messenger after init#998
Conversation
When a plugin gains the Messenger capability after it was first initialized for a user, its plugin conf already exists without an associated internal application (ApplicationID == 0). Messages sent by the plugin were then stored with application_id = 0, orphaning them: they disappeared on reload and could not be deleted (gotify#653). Back-fill the internal application during initialization when a Messenger plugin has none yet, mirroring the creation already done for plugins that support Messenger from the start. Fixes gotify#653 Co-Authored-By: Claude <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #998 +/- ##
==========================================
+ Coverage 74.32% 74.48% +0.16%
==========================================
Files 66 66
Lines 3462 3476 +14
==========================================
+ Hits 2573 2589 +16
+ Misses 689 688 -1
+ Partials 200 199 -1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
eternal-flame-AD
left a comment
eternal-flame-AD
left a comment
There was a problem hiding this comment.
looks good to me, just one thing: can you add a double check in messagehandler.go to do a final check that the application ID is not zero? thanks. I wish we have foreign keys working.
Add a final safety net in redirectToChannel.SendMessage that refuses a message when ApplicationID == 0, so it can never be stored as an orphaned message (application_id = 0, not shown, not deletable). Requested in review. Cover the previously untested error branches around internal-application back-fill (create/update failures) so patch coverage no longer regresses. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Done. Added the safety net in (Prepared with AI assistance, reviewed and verified by me.) |
2 participants
Fixes #653
Problem
When a plugin implements the
plugin.Messengerinterface after it has already been initialized for a user, itsPluginConfalready exists with no associated internal application (ApplicationID == 0). On the next startup,initializeSingleUserPluginreuses that conf and wires the message handler withApplicationID: 0, so every message the plugin sends is stored withapplication_id = 0. Those messages are orphaned: they don't appear after a page refresh and can't be deleted (DELETE returns 404). This matches the maintainer's diagnosis in #653.Fix
On initialization, if a plugin supports
Messengerbut has no internal application yet (ApplicationID == 0), create one and persist it on the conf — mirroring what already happens for plugins that supportMessengerfrom the start. The internal-application creation is extracted into a shared helper. The back-fill is idempotent: plugins that already have an application are untouched.Testing
Added
TestNewManager_MessengerAddedAfterInit_createsApplication, which seeds a conf without an application and asserts an internal application is created after re-initialization with a Messenger-capable plugin. It fails onmaster(ApplicationID stays 0) and passes with this change.go test ./plugin/...,gofmt/gofumpt, andgo vetare clean.Disclosure: this change was prepared with assistance from Claude (an AI tool); all code was reviewed and verified by me.